home *** CD-ROM | disk | FTP | other *** search
/ Space & Astronomy / Space and Astronomy (October 1993).iso / pc / programs / viewers / jpeg3.exe / JPEG.TXT < prev    next >
Text File  |  1992-07-29  |  37KB  |  680 lines
  1. *************************************************************************   
  2.  
  3.  
  4. This FAQ article discusses JPEG image compression.  Suggestions for
  5. additions and clarifications are welcome.
  6.  
  7. New since version of 29 June 1992:
  8.   * xli recommendation upgraded; latest version is 1.09.
  9.   * DVPEG for MS-DOS is up to version 1g.
  10.   * New freeware viewer for MS-DOS, Hiview 1.2.
  11.   * WinJPEG for Windows is up to version 1.2.
  12.   * More detailed info about retrieving MS-DOS programs from Simtel20.
  13.   * JPEGView for Mac is up to version 1.1.
  14.   * Recommendation for "The Data Compression Book" added to section 8.
  15.   * TIFF 6.0 spec is out, but it's still got problems.
  16.  
  17.  
  18. This article includes the following sections:
  19.  
  20. 1)  What is JPEG?
  21. 2)  Why use JPEG?
  22. 3)  How well does it work?
  23. 4)  What are good "quality" settings for JPEG?
  24. 5)  When should I use JPEG, and when should I stick with GIF?
  25. 6)  Where can I get JPEG software?
  26.     6A) "canned" software, viewers, etc.
  27.     6B) source code
  28. 7)  What's all this hoopla about color quantization?
  29. 8)  How does JPEG work?
  30. 9)  What about lossless JPEG?
  31. 10)  Why all the argument about file formats?
  32. 11)  And what about arithmetic coding?
  33. 12)  Does loss accumulate with repeated compression/decompression?
  34.  
  35. Sections 1-6 are basic info that every JPEG user needs to know;
  36. sections 7-12 are advanced info for the curious.
  37.  
  38. ----------
  39.  
  40.  
  41. 1)  What is JPEG?
  42.  
  43. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  44. JPEG stands for Joint Photographic Experts Group, the original name of the
  45. committee that wrote the standard.  JPEG is designed for compressing either
  46. full-color or gray-scale digital images of "natural", real-world scenes.
  47. It does not work so well on non-realistic images, such as cartoons or line
  48. drawings.
  49.  
  50. JPEG does not handle black-and-white (1-bit-per-pixel) images, nor does it
  51. handle motion picture compression.  Standards for compressing those types
  52. of images are being worked on by other committees, named JBIG and MPEG
  53. respectively.
  54.  
  55. JPEG is "lossy", meaning that the image you get out of decompression isn't
  56. quite identical to what you originally put in.  The algorithm achieves much
  57. of its compression by exploiting known limitations of the human eye, notably
  58. the fact that small color details aren't perceived as well as small details
  59. of light-and-dark.  Thus, JPEG is intended for compressing images that will
  60. be looked at by humans.  If you plan to machine-analyze your images, the
  61. small errors introduced by JPEG may be a problem for you, even if they are
  62. invisible to the eye.
  63.  
  64. A useful property of JPEG is that the degree of lossiness can be varied by
  65. adjusting compression parameters.  This means that the image maker can trade
  66. off file size against output image quality.  You can make *extremely* small
  67. files if you don't mind poor quality; this is useful for indexing image
  68. archives, making thumbnail views or icons, etc. etc.  Conversely, if you
  69. aren't happy with the output quality at the default compression setting, you
  70. can jack up the quality until you are satisfied, and accept lesser compression.
  71.  
  72.  
  73. 2)  Why use JPEG?
  74.  
  75. There are two good reasons: to make your image files smaller, and to store
  76. 24-bit-per-pixel color data instead of 8-bit-per-pixel data.
  77.  
  78. Making image files smaller is a big win for transmitting files across
  79. networks and for archiving libraries of images.  Being able to compress a
  80. 2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in
  81. disk space and transmission time!  (If you are comparing GIF and JPEG, the
  82. size ratio is more like four to one.  More details below.)
  83.  
  84. Unless your viewing software supports JPEG directly, you'll have to convert
  85. JPEG to some other format for viewing or manipulating images.  Even with a
  86. JPEG-capable viewer, it takes longer to decode and view a JPEG image than to
  87. view an image of a simpler format (GIF, for instance).  Thus, using JPEG is
  88. essentially a time/space tradeoff: you give up some time in order to store
  89. or transmit an image more cheaply.
  90.  
  91. It's worth noting that when network or phone transmission is involved, the
  92. time savings from transferring a shorter file can be much greater than the
  93. extra time to decompress the file.  I'll let you do the arithmetic yourself.
  94.  
  95. The other reason why JPEG will gradually replace GIF as the standard Usenet
  96. posting format is that JPEG can store full color information: 24 bits/pixel
  97. (16 million colors) instead of 8 or less (256 or fewer colors).  If you have
  98. only 8-bit display hardware then this may not seem like much of an advantage
  99. to you.  Within a couple of years, though, 8-bit GIF will look as obsolete as
  100. black-and-white MacPaint format does today.  Furthermore, for reasons detailed
  101. in section 7, JPEG is far more useful than GIF for exchanging images among
  102. people with widely varying color display hardware.  Hence JPEG is considerably
  103. more appropriate than GIF for use as a Usenet posting standard.
  104.  
  105.  
  106. 3)  How well does it work?
  107.  
  108. Pretty darn well.  Here are some sample file sizes for an image I have handy,
  109. a 727x525 full-color image of a ship in a harbor.  The first three files are
  110. for comparison purposes; the rest were created with the free JPEG software
  111. described in section 6B.
  112.  
  113. File       Size in bytes        Comments
  114.  
  115. ship.ppm    1145040  Original file in PPM format (no compression; 24 bits
  116.              or 3 bytes per pixel, plus a few bytes overhead)
  117. ship.ppm.Z     963829  PPM file passed through Unix compress
  118.              compress doesn't accomplish a lot, you'll note.
  119.              Other text-oriented compressors give similar results.
  120. ship.gif     240438  Converted to GIF with ppmquant -fs 256 | ppmtogif
  121.              Most of the savings is the result of losing color
  122.              info: GIF saves 8 bits/pixel, not 24.  (See sec. 7.)
  123.  
  124. ship.jpg95     155622  cjpeg -Q 95    (highest useful quality setting)
  125.              This is indistinguishable from the 24-bit original,
  126.              at least to my nonprofessional eyeballs.
  127. ship.jpg75      58009  cjpeg -Q 75    (default setting)
  128.              You have to look mighty darn close to distinguish this
  129.              from the original, even with both on-screen at once.
  130. ship.jpg50      38406  cjpeg -Q 50
  131.              This has slight defects; if you know what to look
  132.              for, you could tell it's been JPEGed without seeing
  133.              the original.  Still as good image quality as many
  134.              recent postings in Usenet pictures groups.
  135. ship.jpg25      25192  cjpeg -Q 25
  136.              JPEG's characteristic "blockiness" becomes apparent
  137.              at this setting (djpeg -b helps some).  Still, I've
  138.              seen plenty of Usenet postings that were of poorer
  139.              image quality than this.
  140. ship.jpg5o       6587  cjpeg -Q 5 -o    (-o reduces table overhead)
  141.              Blocky, but perfectly satisfactory for preview or
  142.              indexing purposes.  Note that this file is TINY:
  143.              the compression ratio from the original is 173:1 !
  144.  
  145. In this case JPEG can make a file that's a factor of four or five smaller
  146. than a GIF of comparable quality (the -Q 75 file is every bit as good as the
  147. GIF, better if you have a full-color display).  This seems to be a typical
  148. ratio for real-world scenes.
  149.  
  150.  
  151. 4)  What are good "quality" settings for JPEG?
  152.  
  153. (Note: the -Q settings discussed in this article apply to the free JPEG
  154. software described in section 6B.  Other JPEG implementations, such as Image
  155. Alchemy, may use a completely different quality scale.)
  156.  
  157. The name of the game in using JPEG is to pick the lowest quality setting
  158. (smallest file size) that decompresses into an image indistinguishable from
  159. the original.  This setting will vary from one image to another and from one
  160. observer to another, but here are some rules of thumb.
  161.  
  162. The default quality setting (-Q 75) is very often the best choice.  This
  163. setting is about the lowest you can go without expecting to see defects in a
  164. typical image.  Try -Q 75 first; if you see defects, then go up.  Except for
  165. experimental purposes, never go above -Q 95; saying -Q 100 will produce a
  166. file two or three times as large as -Q 95, but of hardly any better quality.
  167.  
  168. If the image was less than perfect quality to begin with, you might be able to
  169. go down to -Q 50 without objectionable degradation.  On the other hand, you
  170. might need to go to a HIGHER quality setting to avoid further degradation.
  171. The second case seems to apply most of the time when converting GIFs to JPEG.
  172. The default -Q 75 is about right for compressing 24-bit images, but -Q 85 to
  173. 95 is usually better for converting GIFs (see next section for more info).
  174.  
  175. If you want a very small file (say for preview or indexing purposes) and are
  176. prepared to tolerate large defects, a -Q setting in the range of 5 to 10 is
  177. about right.  -Q 2 or so may be amusing as "op art".
  178.  
  179. Another recommendation: when you are making a final version of an image for
  180. posting on Usenet or archiving, specify "-o" to cjpeg.  This will make the
  181. file a little smaller without affecting image quality; it will take longer
  182. to do the compression, but not any longer to decompress.
  183.  
  184.  
  185. 5)  When should I use JPEG, and when should I stick with GIF?
  186.  
  187. As a rule of thumb, JPEG is superior to GIF for storing full-color or
  188. gray-scale images of "realistic" scenes; that means scanned photographs and
  189. similar material.  JPEG is superior even if you don't have 24-bit display
  190. hardware, and it is a LOT superior if you do.  (See section 7 for details.)
  191.  
  192. GIF does significantly better on images with only a few distinct colors,
  193. such as cartoons and line drawings.  In particular, large areas of pixels
  194. that are all *exactly* the same color are compressed very efficiently indeed
  195. by GIF.  JPEG can't squeeze these files as much as GIF does without
  196. introducing visible defects.  This sort of image is best kept in GIF form.
  197. (Incidentally, many people have developed an odd habit of putting a large
  198. constant-color border around a GIF image.  This was nearly free in terms of
  199. storage cost in GIF files.  It is NOT free in JPEG files.  Do yourself a
  200. favor and don't add a border; let your viewer blank out unused screen area.
  201. If you're converting a GIF to JPEG, crop off any border first.)
  202.  
  203. JPEG also has a hard time with very sharp edges: a row of pure-black pixels
  204. adjacent to a row of pure-white pixels, for example.  Sharp edges tend to
  205. come out blurred unless you use a very high quality setting.  Again, this
  206. sort of thing is not found in scanned photographs, but it shows up fairly
  207. often in GIF files: borders, overlaid text, etc.  The blurriness is
  208. particularly objectionable with text that's only a few pixels high.
  209. If you have a GIF with a lot of small-size overlaid text, don't JPEG it.
  210.  
  211. Computer-drawn images (ray-traced scenes, for instance) usually fall between
  212. scanned images and cartoons in terms of complexity.  The more complex and
  213. subtly rendered the image, the more likely that JPEG will do well on it.
  214.  
  215. If you have an existing library of GIF images, you may wonder whether you
  216. should convert them to JPEG.  You will lose some image quality if you do.
  217. (Section 7, which argues that JPEG image quality is superior to GIF, only
  218. applies if both formats start from a full-color original.  If you start from
  219. a GIF, you've already irretrievably lost a great deal of information; JPEG
  220. can only make things worse.)  However, the disk space savings may justify
  221. converting anyway.  This is a decision you'll have to make for yourself.
  222. If you do convert a GIF library to JPEG, I recommend looking at each JPEG
  223. to make sure you are happy with it before throwing away the corresponding
  224. GIF; that will give you a chance to re-do the conversion with a higher
  225. quality setting if necessary.
  226.  
  227. Experience to date suggests that large, high-quality GIFs are the best
  228. candidates for conversion to JPEG.  They chew up the most storage so offer
  229. the most potential savings, and they convert to JPEG with least degradation.
  230. Don't waste your time converting any GIF much under 100 Kbytes.  Also, don't
  231. expect JPEG files converted from GIFs to be as small as those created
  232. directly from full-color originals.  To maintain image quality you may have
  233. to let the converted files be as much as twice as big as straight-through
  234. JPEG files would be (i.e., shoot for 1/2 or 1/3rd the size of the GIF file,
  235. not 1/4th as shown in the earlier comparisons).  A -Q setting of 85 to 95
  236. will minimize the additional degradation caused by converting a GIF to JPEG.
  237.  
  238.  
  239. 6)  Where can I get JPEG software?
  240.  
  241. 6A) If you are looking for "canned" software, viewers, etc:
  242.  
  243. The first part of this list is system-specific programs that only run on one
  244. kind of system.  If you don't see what you want for your machine, check out
  245. the portable JPEG software described at the end of the list.
  246.  
  247. X Windows:
  248.  
  249. John Bradley's free XV (version 2.00 and up) is an excellent viewer for JPEG,
  250. GIF, and other image formats.  It's available for FTP from export.lcs.mit.edu
  251. or ftp.cis.upenn.edu.  The file is called 'xv-???.tar.Z' (where ??? is the
  252. version number, currently 2.21) and is located in the 'contrib' directory on
  253. export or the 'pub/xv' directory at upenn.  XV reduces all images to 8 bits
  254. internally, which means it's not a real good choice if you have a 24-bit
  255. display (you'll still get only 8-bit color).  Also, you shouldn't use XV to
  256. convert full-color images to JPEG, because they'll get color-quantized first.
  257.  
  258. "xli" is less featureful than XV, but it will do the right thing on 24-bit
  259. displays.  xli is free and available from export.lcs.mit.edu, files
  260. contrib/xli.*.  The current version is 1.09.  (At last report, the files at
  261. export were a tar archive of 1.08 and a file of patches to bring 1.08 up to
  262. 1.09; be sure to retrieve both files.)  Alternately, you can use xloadimage
  263. in combination with the free JPEG software described in 6B.
  264.  
  265. Another good choice for X Windows is John Cristy's free ImageMagick package,
  266. also available from export, file contrib/ImageMagick.tar.Z.  The viewer
  267. included in this package handles 24-bit displays correctly; for colormapped
  268. displays, it does better (though slower) color quantization than XV or the
  269. basic free JPEG software.
  270.  
  271. MS-DOS:
  272.  
  273. There are at least two freeware JPEG viewers for plain MS-DOS (non-Windows).
  274.  
  275. One is Eric Praetzel's DVPEG.  The current version, 1g, is available by FTP
  276. from sunee.waterloo.edu, file pub/jpeg/viewers/dvpeg1g.zip.  Version 1g has
  277. a better user interface than previous versions.  It still doesn't work with
  278. every variety of display card, but hey, it's free.
  279.  
  280. A more recent arrival is Mohammad Rezaei's Hiview.  The current version,
  281. 1.2, is available from Simtel20 and mirror sites (see NOTE below), file
  282. msdos/graphics/hv12.zip.  Hiview is noticeably faster than DVPEG and works
  283. on a fairly wide variety of display types.  However, Hiview requires a 386
  284. or better CPU and a VCPI-compatible memory manager (QEMM386 and 386MAX work;
  285. Windows and OS/2 do not).  Also installation is a bit tricky; read the
  286. directions carefully!
  287.  
  288. If neither of these viewers work on your hardware, you'll need to use one of
  289. the following conversion programs to convert JPEG to GIF, then view with
  290. your favorite GIF viewer.  (If you have hi-color hardware, don't use GIF
  291. as the intermediate format; try to find a TARGA-capable viewer instead.)
  292.  
  293. The Independent JPEG Group's free JPEG converters are FTPable from Simtel20
  294. and mirror sites (see NOTE below), file msdos/graphics/jpeg3.zip (or
  295. jpeg3386.zip if you have a 386 and extended memory).  The same files were
  296. posted to comp.binaries.ibm.pc (volume 18, issues 123-130) and should be
  297. available from any c.b.i.p archive site.  These files are DOS compilations
  298. of the free source code described in section 6B.
  299.  
  300. Handmade Software offers two rather pricy shareware programs: Image Alchemy
  301. and GIF2JPG/JPG2GIF (contact hsi@netcom.com for details).  The PC versions
  302. of these programs are FTPable from Simtel20 and mirror sites (see NOTE
  303. below), files msdos/graphics/alchmy15.zip and gif2jpg5.zip.  GIF2JPG/JPG2GIF
  304. only performs JPEG<=>GIF format conversion.  Image Alchemy converts files
  305. between these and many other formats, and can also display images on some
  306. types of hardware.  The display option is limited and not very high quality,
  307. so you'll still want a separate viewer program.  (CAUTION: GIF2JPG produces
  308. a proprietary file format unless you specify -j.  Be sure to use -j if you
  309. want to exchange JPEG files with other Usenet users.  For that matter, it's
  310. not real clear that you should be posting JPEG files made from GIFs; see
  311. section 5.)
  312.  
  313. In my biased opinion, the free JPEG software is a better choice than
  314. GIF2JPG/JPG2GIF; it's faster, as good or better image quality, and free :-).
  315. On the other hand, Image Alchemy may be worth its price, if you need the
  316. additional conversion and image manipulation capabilities it provides.
  317.  
  318. NOTE ABOUT SIMTEL20: The Internet's key archive site for PC-related programs
  319. is Simtel20, full name wsmr-simtel20.army.mil (192.88.110.20).  Simtel20
  320. runs a non-Unix operating system; where this document refers to directory
  321. (eg) "msdos/graphics" at Simtel20, that really means "pd1:<msdos.graphics>".
  322. If you are not physically on MILnet, you should expect rather slow FTP
  323. transfer rates from Simtel20.  There are several Internet sites that
  324. maintain copies (mirrors) of the Simtel20 archives; most FTP users should
  325. go to one of the mirror sites instead.  A popular USA mirror site is
  326. wuarchive.wustl.edu (128.252.135.4); it keeps Simtel20 files in (eg)
  327. "/mirrors/msdos/graphics".  If you have no FTP capability, you can retrieve
  328. files from Simtel20 by e-mail; see informational postings in
  329. comp.binaries.ibm.pc.archives to find out how.  If you are outside the USA,
  330. consult the same newsgroup to learn where your nearest Simtel20 mirror is.
  331.  
  332. Microsoft Windows:
  333.  
  334. There are a couple of shareware Windows JPEG viewers available by FTP.
  335. 1. WinJPEG.  Current version is 1.2, available from Simtel20 and mirror
  336. sites (see NOTE above), file msdos/windows3/winjp120.zip.
  337. 2. ColorView.  Current version is 0.97, available from wuarchive.wustl.edu:
  338. mirrors/win3/desktop/cview097.zip.
  339. WinJPEG is faster and more robust than the current prototype version of
  340. ColorView, but they have different features so you may want to try both.
  341. (No new version of ColorView has appeared in some time, so it's not clear
  342. whether it is being actively maintained.  WinJPEG IS getting upgraded.)
  343.  
  344. At least two freeware Windows JPEG viewers are also undergoing beta test and
  345. should be out shortly; watch this space...
  346.  
  347. The DOS conversion programs described above will run inside a Windows DOS
  348. window.  Note that Windows viewers are generally slower than non-Windows
  349. viewers on the same hardware, due to Windows' system overhead.
  350.  
  351. Macintosh:
  352.  
  353. Apple has released a free program called PictPixie (formerly known as
  354. PictCompressor) that can convert the Usenet-standard JFIF JPEG format to and
  355. from QuickTime's internal JPEG format.  PictPixie can also be used as a
  356. viewer for JFIF, QuickTime JPEG, and GIF files.  You can get PictPixie from
  357. ftp.apple.com, file dts/mac/quicktime/pictpixie.hqx.  You need both
  358. QuickTime and 32-bit QuickDraw to run PictPixie (and therefore you must be
  359. running System 6.0.7 or later).  You can get QuickTime from the same FTP
  360. directory; I think 32-bit QuickDraw is an optional item on the System 6.0.7
  361. disks.  PictPixie is considered a developer's tool; you may not care for its
  362. user interface.  There is a simplified version of this program in the
  363. QuickTime Starter Kit.
  364.  
  365. Another good choice is JPEGView, a free program for viewing both JFIF and
  366. QuickTime JPEG files, as well as converting between the two formats.
  367. The current version, 1.1, is much improved over the initial release (0.9).
  368. Get it from sumex-aim.stanford.edu, file /info-mac/app/jpeg-view-11.hqx.
  369. This program requires System 7 and QuickTime.  It doesn't do quite as much
  370. as PictPixie, but it is fast and handier than PictPixie for skimming through
  371. lots of images.
  372.  
  373. Storm Technology has released a free JPEG viewer called Picture Decompress.
  374. This is generally inferior to PictPixie or JPEGView, but it will run without
  375. System 7 or QuickTime, so you may be forced to use it on older systems.
  376. You'll still need 32-bit QuickDraw, though.  This program can be FTPed from
  377. sumex-aim.stanford.edu, file /info-mac/app/picture-decompress-201.hqx.  Make
  378. sure you get version 2.0.1 or later; earlier versions are not compatible
  379. with JFIF file format.  You'll also need a tool for adjusting file type
  380. codes; you must set the type of a downloaded image file to 'JPEG' to allow
  381. Picture Decompress to open it.
  382.  
  383. On 8-bit-color Macs, none of the above programs produce really high quality
  384. displays, since they do quick-and-dirty color reduction (this is not a
  385. problem if you are fortunate enough to have a 24-bit display).  I hear that
  386. PictPixie does a little better than the other two programs.  (The free JPEG
  387. software, described later, does a much better job of reducing JPEG images
  388. to 8-bit color.  Unfortunately, no one has gotten around to releasing a
  389. precompiled version of the free software for Macintoshes.  This should
  390. change soon.)
  391.  
  392. Amiga:
  393.  
  394. I'm told the shareware program HAMLab is about the best tool for viewing/
  395. converting JPEG files.  This should be available from most big Amiga archive
  396. sites.
  397.  
  398. Portable software for almost any system:
  399.  
  400. If none of the above fits your situation, you can obtain and compile the free
  401. JPEG conversion software described in 6B.  You'll also need a viewer program.
  402. If your display is 8 bits or less, any GIF viewer will do fine; if you have a
  403. display with more color capability, try to find a viewer that can read Targa
  404. or PPM 24-bit image files.
  405.  
  406. If you are not reasonably handy at configuring and installing portable C
  407. programs, you may have some difficulty installing the free source code.
  408. Steve Davis (strat@cis.ksu.edu) has volunteered to maintain an archive of
  409. pre-built executable versions of the free JPEG code for various machines.
  410. His FTP archive is at ftp.cis.ksu.edu (129.130.10.80); look under /pub/JPEG
  411. to see what he currently has.  (The administrators of this system ask that
  412. FTP traffic be limited to non-prime hours.)  This archive is not maintained
  413. by the Independent JPEG Group, and files in it may not represent the latest
  414. free source code.  (Actually, Steve has gotten pretty lax about maintaining
  415. his archive.  Any volunteers to set up a new one?)
  416.  
  417. There are numerous commercial JPEG offerings, with more popping up every
  418. day.  I recommend that you not spend money on one of these unless you find
  419. the available free or shareware software vastly too slow.  In that case,
  420. purchase a hardware-assisted product.  Ask pointed questions about whether
  421. the product complies with the final JPEG standard and about whether it can
  422. handle the JFIF file format; many of the earliest commercial releases are
  423. not and never will be compatible with anyone else's files.
  424.  
  425.  
  426. 6B) If you are looking for source code to work with:
  427.  
  428. Free, portable C code for JPEG compression is available from the Independent
  429. JPEG Group, which I lead.  A package containing our source code,
  430. documentation, and some small test files is available from several places.
  431. The "official" archive site for this source code is ftp.uu.net (137.39.1.9
  432. or 192.48.96.9).  Look under directory /graphics/jpeg; the current release
  433. is jpegsrc.v3.tar.Z.  (This is a compressed TAR file; don't forget to
  434. retrieve in binary mode.)  You can retrieve this file by FTP or UUCP.
  435. Folks in Europe may find it easier to FTP from nic.funet.fi (see directory
  436. pub/graphics/programs/jpeg).  The source code is also available on
  437. CompuServe, in the GRAPHSUPPORT forum (GO PICS), library 10, as jpsrc3.zip.
  438. If you have no FTP access, you can retrieve the source from your nearest
  439. comp.sources.misc archive; version 3 appeared as issues 1-18 of volume 29.
  440. (See the "How to find sources" FAQ article, which appears regularly in
  441. news.answers, if you don't know how to retrieve comp.sources.misc postings.)
  442.  
  443. The free JPEG code provides conversion between JPEG "JFIF" format and image
  444. files in GIF, PBMPLUS PPM/PGM, Utah RLE, and Truevision Targa file formats.
  445. The core compression and decompression modules can easily be reused in other
  446. programs, such as image viewers.  The package is highly portable; we have
  447. tested it on many machines ranging from PCs to Crays.
  448.  
  449. We have released this software for both noncommercial and commercial use.
  450. Companies are welcome to use it as the basis for JPEG-related products.
  451. We do not ask a royalty, although we do ask for an acknowledgement in
  452. product literature (see the README file in the distribution for details).
  453. We hope to make this software industrial-quality --- although, as with
  454. anything that's free, we offer no warranty and accept no liability.
  455.  
  456. The Independent JPEG Group is a volunteer organization; if you'd like to
  457. contribute to improving our software, you are welcome to join.
  458.  
  459.  
  460. 7)  What's all this hoopla about color quantization?
  461.  
  462. Most people don't have full-color (24 bit per pixel) display hardware.
  463. Typical display hardware stores 8 or fewer bits per pixel, so it can display
  464. 256 or fewer distinct colors at a time.  To display a full-color image, the
  465. computer must map the image into an appropriate set of representative
  466. colors.  This process is called "color quantization".  (This is something
  467. of a misnomer, "color selection" would be a better term.  We're stuck with
  468. the standard usage though.)
  469.  
  470. Clearly, color quantization is a lossy process.  It turns out that for most
  471. images, the details of the color quantization algorithm have MUCH more impact
  472. on the final image quality than do any errors introduced by JPEG (except at
  473. the very lowest JPEG quality settings).
  474.  
  475. Since JPEG is inherently a full-color format, converting a JPEG image for
  476. display on 8-bit-or-less hardware requires color quantization.  On the other
  477. hand, a GIF image by definition has already been quantized to 256 or fewer
  478. colors.  For purposes of Usenet picture distribution, GIF has the advantage
  479. that the sender precomputes the color quantization, so recipients don't have
  480. to.  This is also the *disadvantage* of GIF: you're stuck with the sender's
  481. quantization.  If the sender quantized to a different number of colors than
  482. what you can display, you have to re-quantize, resulting in much poorer
  483. image quality than if you had quantized once from a full-color image.
  484. Furthermore, if the sender didn't use a high-quality color quantization
  485. algorithm, you're out of luck.
  486.  
  487. For this reason, JPEG offers the promise of significantly better image quality
  488. for all users whose machines don't match the sender's display hardware.
  489. JPEG's full color image can be quantized to precisely match the user's display
  490. hardware.  Furthermore, you will be able to take advantage of future
  491. improvements in quantization algorithms (there is a lot of active research in
  492. this area), or purchase better display hardware, to get a better view of JPEG
  493. images you already have.  With a GIF, you're stuck forevermore with what was
  494. sent.
  495.  
  496. It's also worth mentioning that many GIF-viewing programs include rather
  497. shoddy quantization routines.  If you view a 256-color GIF on a 16-color EGA
  498. display, for example, you are probably getting a much worse image than you
  499. need to.  This is partly an inevitable consequence of doing two color
  500. quantizations (one to create the GIF, one to display it), but often it's
  501. also due to sloppiness.  JPEG conversion programs will be forced to use
  502. high quality quantizers in order to get acceptable results at all, and in
  503. normal use they will quantize directly to the number of colors to be
  504. displayed.  Thus, JPEG is likely to provide better results than the average
  505. GIF program for low-color-resolution displays as well as high-resolution ones!
  506.  
  507.  
  508. 8)  How does JPEG work?
  509.  
  510. The buzz-words to know are chrominance subsampling, discrete cosine
  511. transforms, coefficient quantization, and Huffman or arithmetic entropy
  512. coding.  This article's long enough already, so I'm not going to say more
  513. than that.  For a good technical introduction, see:
  514.     Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
  515.     Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
  516. (Adjacent articles in that issue discuss MPEG motion picture compression,
  517. applications of JPEG, and related topics.)  If you don't have the CACM issue
  518. handy, a PostScript file containing a revised version of this article is
  519. available at ftp.uu.net, graphics/jpeg/wallace.ps.Z.  The file (actually a
  520. preprint for an article to appear in IEEE Trans. Consum. Elect.) omits the
  521. sample images that appeared in CACM, but it includes corrections and some
  522. added material.  Note: the Wallace article is copyright ACM and IEEE, and
  523. it may not be used for commercial purposes.
  524.  
  525. An alternative, more leisurely explanation of JPEG can be found in "The Data
  526. Compression Book" by Mark Nelson, published by M&T Books (Redwood City, CA),
  527. 1991, ISBN 1-55851-216-0.  This book provides excellent introductions to
  528. many data compression methods including JPEG, plus sample source code in C.
  529. The JPEG-related source code is far from industrial-strength, but it's a
  530. pretty good learning tool.  (When you are ready to look at a real
  531. implementation, see section 6B.)
  532.  
  533.  
  534. 9)  What about lossless JPEG?
  535.  
  536. There's a great deal of confusion on this subject.  The JPEG committee did
  537. define a truly lossless compression algorithm, i.e., one that guarantees the
  538. final output is bit-for-bit identical to the original input.  However, this
  539. lossless mode has almost nothing in common with the regular, lossy JPEG
  540. algorithm.  At present, very few implementations of lossless JPEG exist,
  541. and all of them are commercial.
  542.  
  543. Saying "-Q 100" to the free JPEG software DOES NOT get you a lossless image.
  544. What it does get rid of is deliberate information loss in the coefficient
  545. quantization step.  There is still a good deal of information loss in the
  546. color subsampling step.  (There should be a command line switch to disable
  547. subsampling, but as of today, there isn't one.)
  548.  
  549. Even with both quantization and subsampling turned off, the regular JPEG
  550. algorithm is not lossless, because it is subject to roundoff errors in
  551. various calculations.  The maximum error is a few counts in any one pixel
  552. value; it's highly unlikely that this could be perceived by the human eye,
  553. but it might be a concern if you are doing machine processing of an image.
  554.  
  555. At this minimum-loss setting, regular JPEG produces files that are perhaps
  556. half the size of an uncompressed 24-bit-per-pixel image.  True lossless JPEG
  557. provides roughly the same amount of compression, but it guarantees
  558. bit-for-bit accuracy.
  559.  
  560. If you have an application requiring lossless storage of images with less
  561. than 6 bits per pixel (per color component), you may want to look into the
  562. JBIG bilevel image compression standard.  This performs better than JPEG
  563. lossless on such images.  JPEG lossless is superior to JBIG on images with
  564. 8 or more bits per pixel; furthermore, it is public domain, while the JBIG
  565. techniques are heavily covered by patents.
  566.  
  567.  
  568. 10)  Why all the argument about file formats?
  569.  
  570. Strictly speaking, JPEG refers only to a family of compression algorithms;
  571. it does *not* refer to a specific image file format.  The JPEG committee was
  572. prevented from defining a file format by turf wars within the international
  573. standards organizations.
  574.  
  575. Since we can't actually exchange images with anyone else unless we agree on
  576. a common file format, this leaves us with a problem.  In the absence of
  577. official standards, a number of JPEG program writers have just gone off to
  578. "do their own thing", and as a result their programs aren't compatible with
  579. anybody else's.
  580.  
  581. The closest thing we have to a de-facto standard JPEG format is some work
  582. that's been coordinated by people at C-Cube Microsystems.  They have defined
  583. two JPEG-based file formats:
  584.   * JFIF (JPEG File Interchange Format), a "low-end" format that transports
  585.     pixels and not much else.
  586.   * TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format.  TIFF is
  587.     a "high-end" format that will let you record just about everything you
  588.     ever wanted to know about an image, and a lot more besides :-).  TIFF is
  589.     a lot more complex than JFIF, and may well prove less transportable,
  590.     because different vendors have historically implemented slightly different
  591.     and incompatible subsets of TIFF.  It's not likely that adding JPEG to the
  592.     mix will do anything to improve this situation.
  593. Both of these formats were developed with input from all the major vendors
  594. of JPEG-related products; it's reasonably likely that future commercial
  595. products will adhere to one or both standards.
  596.  
  597. A particular case that people may be interested in is Apple's QuickTime
  598. software for the Macintosh.  QuickTime uses a JFIF-compatible format wrapped
  599. inside the Mac-specific PICT structure.  Conversion between JFIF and
  600. QuickTime JPEG is pretty straightforward; in fact Apple has released a
  601. utility program for the purpose (see PictPixie in section 6A).
  602.  
  603. I believe that Usenet should adopt JFIF as the replacement for GIF in
  604. picture postings.  JFIF is simpler than TIFF and is available now; the
  605. TIFF 6.0 spec has only recently been officially adopted, and it is still
  606. unusably vague on some crucial details.  Even when TIFF/JPEG is well
  607. defined, the JFIF format is likely to be a widely supported "lowest common
  608. denominator"; TIFF/JPEG files may never be as transportable.
  609.  
  610.  
  611. 11)  And what about arithmetic coding?
  612.  
  613. The JPEG spec defines two different "back end" modules for the final output
  614. of compressed data: either Huffman coding or arithmetic coding is allowed.
  615. The choice has no impact on image quality, but arithmetic coding usually
  616. produces a smaller compressed file.  On typical images, arithmetic coding
  617. produces a file 5 or 10 percent smaller than Huffman coding.  (All the
  618. file-size numbers previously cited are for Huffman coding.)
  619.  
  620. Unfortunately, the particular variant of arithmetic coding specified by the
  621. JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
  622. Thus *you cannot legally use arithmetic coding* unless you obtain licenses
  623. from these companies.  (The "fair use" doctrine allows people to implement
  624. and test the algorithm, but actually storing any images with it is dubious
  625. at best.)
  626.  
  627. At least in the short run, I recommend that people not worry about
  628. arithmetic coding; the space savings isn't great enough to justify the
  629. potential legal hassles.  In particular, arithmetic coding *should not*
  630. be used for any images to be exchanged on Usenet.
  631.  
  632. There is some small chance that the legal situation may change in the
  633. future.  Stay tuned for further details.
  634.  
  635.  
  636. 12)  Does loss accumulate with repeated compression/decompression?
  637.  
  638. It would be nice if, having compressed an image with JPEG, you could
  639. decompress it, manipulate it (crop off a border, say), and recompress it
  640. without any further image degradation beyond what you lost initially.
  641. Unfortunately THIS IS NOT THE CASE.  In general, recompressing an altered
  642. image loses more information, though usually not as much as was lost the
  643. first time around.
  644.  
  645. The next best thing would be that if you decompress an image and recompress
  646. it *without changing it* then there is no further loss, i.e., you get an
  647. identical JPEG file.  Even this is not true; at least, not with the current
  648. free JPEG software.  It's essentially a problem of accumulation of roundoff
  649. error.  If you repeatedly compress and decompress, the image will eventually
  650. degrade to where you can see visible changes from the first-generation
  651. output.  (It usually takes many such cycles to get visible change.)
  652. One of the things on our to-do list is to see if accumulation of error can
  653. be avoided or limited, but I am not optimistic about it.
  654.  
  655. In any case, the most that could possibly be guaranteed would be that
  656. compressing the unmodified full-color output of djpeg, at the original
  657. quality setting, would introduce no further loss.  Even such simple changes
  658. as cropping off a border could cause further roundoff-error degradation.
  659. (If you're wondering why, it's because the pixel-block boundaries move.
  660. If you cropped off only multiples of 16 pixels, you might be safe, but
  661. that's a mighty limited capability!)
  662.  
  663. The bottom line is that JPEG is a useful format for archival storage and
  664. transmission of images, but you don't want to use it as an intermediate
  665. format for sequences of image manipulation steps.  Use a lossless format
  666. (PPM, RLE, TIFF, etc) while working on the image, then JPEG it when you are
  667. ready to file it away.  Aside from avoiding degradation, you will save a lot
  668. of compression/decompression time this way :-).
  669.  
  670.  
  671. ---------------------
  672.  
  673. For more information about JPEG in general or the free JPEG software in
  674. particular, contact the Independent JPEG Group at jpeg-info@uunet.uu.net.
  675.  
  676. -- 
  677.             tom lane
  678.             organizer, Independent JPEG Group
  679. Internet: tgl@cs.cmu.edu    BITNET: tgl%cs.cmu.edu@carnegie
  680.